今年，AI大廠採購GPU的投入又雙轟瘋狂加碼——馬斯克xAI打算把自家的10萬卡超算擴增10倍，Meta也計畫投資100億建設一個130萬卡規模的資料中心……GPU的數量，已經成為了網際網路企業AI實力的直接代表。的確，建設AI算力，這種堆卡模式是最簡單粗暴的，但實際上，AI叢集卻並非是卡越多就越好用。GPU雖然計算性能好，但是在叢集化的模式下依然有很多挑戰，即便強如輝達，也面臨通訊瓶頸、記憶體碎片化、資源利用率波動等問題。簡單說就是，由於通訊等原因的限制，GPU的功力沒辦法完全發揮出來。所以，建設AI時代的雲資料中心，不是把卡堆到機櫃裡就能一勞永逸，現有資料中心的不足，需要用架構的創新才能解決。最近，華為發佈了一篇60頁的重磅論文，提出了他們的下一代AI資料中心架構設計構想——Huawei CloudMatrix，以及該構想的第一代產品化的實現CloudMatrix384。相對於簡單的“堆卡”，華為CloudMatrix給出的架構設計原則是，高頻寬全對等互連和細粒度資源解耦。這篇論文乾貨滿滿，不僅展示了CloudMatrix384的詳細硬體設計，並介紹了基於CloudMatrix384進行DeepSeek推理的最佳實踐方案——CloudMatrix-Infer。那麼，華為提出的CloudMatrix384到底有多強？簡單地說，可以概括成三個方面——夠高效：預填充吞吐量達6688 token/s/NPU，解碼階段1943 token/s/NPU；計算效率方面，預填充達4.45 token/s/TFLOPS，解碼階段1.29 token/s/TFLOPS,均超過業績在NVIDIA H100/H800上實現的性能；夠準確：DeepSeek-R1模型在昇騰NPU上INT8量化的基準測試精度與官方API一致；夠靈活：支援動態調整推理時延SLO，在15ms嚴格延遲約束下仍維持538 token/s解碼吞吐量。AI資料中心架構，華為雲提前邁出了一步在深入剖析這篇重磅論文之前，我們有必要先來瞭解一下“Why we need CloudMatrix384”。若是一句話來概括，就是滿足不了當下AI發展的算力需求。因為傳統的AI叢集，它內部運行的過程更像是“分散的小作坊”，每個伺服器（節點）有種各玩各的感覺；算力、記憶體和網路資源等等，都是被固定分配的。在這種傳統模式下，AI叢集一旦遇到超大規模的模型，就會出現各種問題，例如算力不夠、記憶體頻寬卡脖子、節點間通訊慢如蝸牛等等。而華為在這篇論文中要做的事情，就是提出一種新的模式，把這種“小作坊”改成“超級算力工廠”——以CloudMatrix（首個生產級實現CloudMatrix384）為代表的華為雲下一代AI資料中心架構。它最鮮明的一大特點就是，所有的資源是可以統一調度的：CloudMatrix384把384個NPU、192個CPU以及其它硬體都整合到了一個超級節點當中。因此在這裡，像剛才提到的算力、記憶體、網路資源等等，會像工廠裡的流水線一樣被統一管理起來，那裡需要就調那裡。並且資料在CloudMatrix384里，就像是搭乘了工廠裡的高速傳送帶，因為所有晶片的連接都是由超高頻寬、低延遲的統一匯流排（UB）網路完成，資料在晶片之間是“全對等”直接傳輸，這就避免了傳統網路“堵車”的問題。也正因如此，無論CloudMatrix384是遇到多大參數規模的大模型，亦或是需要頻繁訪問快取的推理任務，都能通過動態分配資源，高效完成計算。△華為CloudMatrix架構願景在瞭解完下一代AI資料中心的設計願景之後，我們繼續深扒一下細節創新技術和獨特優勢。全對等互聯：華為提前邁出的重要的一步全對等互聯（Peer-to-Peer），可以說是CloudMatrix384在硬體架構設計上的一大創新之處。因為傳統的AI叢集中，CPU相當於扮演一個“領導”的角色，NPU等其它硬體更像是“下屬”，資料傳輸的過程中就需要CPU“審批簽字”，效率自然就會大打折扣。尤其是在處理大規模模型的時候，通訊開銷甚至可以佔整體任務時長的40%！但在CloudMatrix384中，情況就截然不同了。CPU和NPU等硬體更像是一個“扁平化管理的團隊”，它們之間的地位比較平等，直接通過UB網路通訊，省去了“領導傳話”的時間。△CloudMatrix384全對等互聯硬體架構設計而實現如此“扁平化管理團隊”的關鍵，就是我們剛才提到的UB網路，是一種無阻塞全連接拓撲。它採用Clos架構設計，16個機架中的L1/L2交換機形成多層級無阻塞網路，可以確保任意兩個NPU/CPU間通訊頻寬恆定。而在傳統叢集中，節點間是通過RoCE網路來通訊，頻寬通常僅為200Gbps（約25GB/s），並且還存在 “南北向頻寬瓶頸”（如資料中心核心交換機負載過高）。但在UB網路的加持下，每個NPU可以提供392GB/s的單向頻寬，相當於每秒能傳48部1080P電影，資料傳輸又快又穩。除此之外，傳統NPU之間通訊還依賴SDMA引擎（類似 “快遞中轉站”），它的缺點就是啟動延遲比較高（約10微秒）。為此，全對等互聯引入了AIV直連（AIV-Direct）的機制，它可以直接通過UB網路寫入遠端NPU記憶體，跳過SDMA的中轉，傳輸啟動延遲從10微秒降至1微秒以內。這個機制就非常適合MoE中token分發等高頻通訊的場景，把單次通訊耗時縮短70%以上。但除了硬體上的設計之外，軟體層面的加持對於CloudMatrix384的高效率也是起到了功不可沒的作用。例如UB網路通過結合記憶體池化技術，實現了CloudMatrix384的“全域記憶體檢視”，即所有NPU/CPU可直接訪問跨節點記憶體，無需關心資料物理位置。解碼階段的NPU可直接讀取預填充階段NPU生成的KV快取，不用再通過CPU中轉或磁碟儲存，資料訪問延遲從毫秒級降至微秒級，快取命中率提升至56%以上。再以671B的DeepSeek-R1為例，通過FusedDispatch融合算子與AIV直連，token分發延遲從800微秒降至300微秒。預填充計算效率提升4.45 token/秒/TFLOPS，超越了輝達H100的3.75 token/秒/TFLOPS。並且在TPOT<50ms的約束下，解碼吞吐量達到了1943 token/秒/每NPU，即使收緊至TPOT<15ms，仍能維持538 token/秒，這就驗證了全對等互聯在嚴苛延遲場景下的穩定性。因為雲原生：不用關心硬體細節，華為雲上開箱即用除了“全對等互聯”之外，這篇重磅論文的第二個技術關鍵詞，非“雲”莫屬了。簡單來說，這是一套面向雲的基礎設施軟體棧，它就像一個“智能管家團隊”，可以把複雜的硬體裝置變成人人能用的 “雲端算力超市”。值得一提的是，早在CloudMatrix384問世之前，華為雲團隊早早地就敲定下一代AI資料中心要以“面向雲”為基礎，這就體現了華為在技術戰略佈局上的前瞻性。並且團隊通過兩年多時間的打磨，已經讓部署CloudMatrix384這事變成“零門檻”，使用者無需關心硬體細節直接可以部署。△部署CloudMatrix384的華為雲基礎設施軟體棧整體來看，這套面向雲的基礎設施軟體棧主要包含以下幾大模組：MatrixResource、MatrixLink、MatrixCompute、MatrixContainer，以及頂層的ModelArts平台，它們之間可以說是分工明確且相互協作。首先我們來看下MatrixResource。它在軟體棧中起到的是“資源分配管家”的作用，主要負責超級節點內物理資源的供應，包括基於拓撲感知的計算實例分配。通過運行在每個計算節點擎天卡上的MatrixResource代理，動態管理NPU、CPU等硬體資源的分配，確保資源按拓撲結構高效調度，避免跨節點通訊瓶頸。MatrixLink則是一位“網路通訊管家”。它為UB和RDMA網路提供服務化功能，支援QoS保障、動態路由及網路感知的工作負載放置。可以最佳化超節點內384個NPU及跨節點間的通訊效率，例如在推理場景中通過平行傳輸和多路徑負載平衡技術，輔助提升推理效率20%。MatrixCompute的角色像是“邏輯超節點管家”。它的任務是管理超節點的 “生老病死”，從開機啟動到故障修復全負責，包括裸金屬供應、自動擴縮容、故障恢復等。具體實現的方式是跨物理節點編排資源，將分散的硬體元件建構為緊密耦合的邏輯超級節點實例，實現資源的彈性擴展和高可用性。MatrixContainer是“容器部署管家”。它的作用是讓使用者的AI應用能像 “快遞包裹” 一樣輕鬆部署到超節點上：基於Kubernetes容器技術，把複雜的AI程序打包成標準化容器，使用者只需“點選部署”，它就會自動安排到合適的硬體上運行。最後，就是ModelArts這位“AI全流程管家”了。它位於整個軟體棧的頂層，提供從模型開發、訓練到部署的全流程服務，包括ModelArts Lite（裸金屬/容器化硬體訪問）、ModelArts Standard（完整MLOps流水線）、ModelArts Studio（模型即服務，MaaS）。新手可以用ModelArts Lite直接呼叫硬體算力；進階使用者可以用ModelArts Standard管理訓練、最佳化、部署全流程；企業使用者則可以用ModelArts Studio把模型變成API服務（如聊天機器人），一鍵發佈。由此可見，在CloudMatrix384本身高效的基礎上，面向雲的基礎設施軟體棧起到了“如虎添翼”的作用，使得部署這件事變得更加便捷。軟硬一體：高效、便捷的同時，也夠靈活除了“全對等互聯”和“雲原生”這兩個關鍵詞，論文中也還涉及到了二者“軟硬一體”結合下，在靈活性上體現出來的優勢。例如剛才我們提到的“使用者無需關注底層硬體細節，只需呼叫API”這方面，具體而言，是華為雲EMS（彈性記憶體服務）通過記憶體池化技術，將CPU連接的DRAM聚合為共用記憶體池，NPU可直接訪問遠端記憶體，實現KV快取復用，使首Token時延降低 80%，同時減少NPU購買量約50%。以及MatrixCompute支援超節點實例的自動擴縮容，例如根據工作負載動態調整預填充/解碼叢集的NPU數量，在嚴苛的15ms TPOT約束下仍能維持538 token/秒的解碼吞吐量。通過確定性維運服務和昇騰雲腦技術，還可以實現萬卡叢集故障10分鐘內恢復，HBM和網路鏈路故障場景下恢復時間挑戰30秒，例如光模組故障影響降低96%，保障訓練/推理任務的連續性。軟體棧還支援超節點資源的多租戶切分，不同使用者可共享硬體資源但邏輯隔離，例如通過命名空間隔離不同模型的快取資料，確保資料安全與資源公平分配。通過智能化調度實現“朝推夜訓”，白天運行推理任務，夜間利用閒置算力進行模型訓練，節點在訓練/推理間切換<5分鐘，提升算力利用率。據瞭解，CloudMatrix384已經在華為雲烏蘭察布、和林格爾、貴安、蕪湖四大節點上線，使用者可按需開通算力，無需自行搭建硬體環境，10毫秒時延圈覆蓋全國19個城市群，支援低延遲訪問。並且CloudMatrix384還提供全端智能維運的能力，例如昇騰雲腦的故障知識庫已經覆蓋了95%的常見場景，一鍵診斷的精準率達到了80%、網路故障診斷＜10分鐘，可以說是把維運的門檻也打了下去。打破“不可能三角”看到這裡，我們可以做個簡單總結了。華為的CloudMatrix384通過“全對等架構+軟硬協同”的模式，打破了傳統上算力、延遲和成本之間的“不可能三角”。硬體層面，它的全對等UB匯流排實現392GB/s卡間頻寬，讓384張NPU能夠高效協同工作，在EP320專家平行模式下，token分發延遲控制在100微秒以內。軟體層面的CloudMatrix-Infer採用全對等推理架構、大EP平行、昇騰定製融合算子、UB驅動的分離式記憶體池等，最大化發揮硬體效率。這種設計讓高算力、低延遲、可控成本同時成為可能，總之有了CloudMatrix384，雲端的大模型部署方案變得更香了。雲端可以在資料中心等級進行統一規劃，建構專門的高速網路拓撲，突破單一企業的物理限制。更關鍵的是，雲端支援彈性擴縮容，企業可以根據業務需求動態調整資源規模，從幾十張卡擴展到數百張卡，而無需對物理設施進行改動。而且，選擇雲也意味著不需要使用者自己找專業團隊去處理模型最佳化、分佈式訓練、故障處理等複雜問題。CloudMatrix384的維運自動化設計更是將故障影響降低96%，萬卡叢集故障恢復時間控制在5分鐘以內，這種專業化維運能力是大部分企業無法自建的。更重要的，CloudMatrix384代表的雲端AI服務模式為中國企業提供了一個更現實的AI落地路徑。比如DeepSeek-R1從模型遷移到上線僅用72小時，相比傳統方案的2周時間，效率提升顯著。這種成本和效率優勢讓更多企業能夠嘗試AI應用，而不需要承擔巨額的基礎設施投入風險。CloudMatrix384證明了國產雲端方案不只是“能用”，更是在性能和成本效益上都具備競爭優勢。AI基礎設施正在重新被定義CloudMatrix384代表的不只是一台更強的AI超算，還是對“什麼是AI基礎設施”的重新定義。技術上，它通過UB顛覆了過往以CPU為中心的層級式設計，將整個超級節點變成了一個統一的計算實體。面向未來，華為論文中也給出了兩條發展路徑——一方面繼續擴大節點規模，另一方面進行更強力的解耦。擴大規模容易理解，未來LLM參數規模更大，需要更緊密耦合的計算資源。而解耦，可以分別從資源和應用兩個維度來看。資源上，CPU和NPU資源物理將分離為專用資源池，從邏輯解耦將走向物理解耦，實現更好的資源利用率。應用中，大模型的推理過程中記憶體密集型注意力計算將從解碼路徑解耦，注意力和專家元件也會分離為獨立執行服務。總之，作者描繪了一個完全解耦、自適應、異構的AI資料中心架構，這種架構將進一步提升可擴展性、靈活性、效率和性能。未來，計算資源將不再是固定的物理裝置，而是可以動態編排的抽象能力。通過CloudMatrix384和其未來暢想，我們正在見證又一次新的技術迭代，也在見證整個AI資料中心範式的深刻變革。 (量子位)